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I. INTRODUCTION 


me OLJECTIVES 

system initialization is the method used to get an 
operating system loaded and running on a computer system. 
This is a recurring requirement that must be accomplished 
mem time the computer is powered up anc each time the user 
wisnes to change from one operating system to another. This 
thesis presents a versatile, simple to understand, and 
widely applicable SyStem initialization mechanism based on a 
careful sequencing of the initialization activities. These 
Meeevities will be performed in one of the three system 
initialization phases addressed in this thesis based upon 
which phase provides the most Supportive environment for 
men particular activity. 

Traditionally, operating system designers have ignored 
the system Wont ed ttre t 10 n problem Une! the pana | 
development stages. AS a result, most existing system 
Mmmrtidlizetion schemes are rather ad-hoc, using a mass of 
"special Case sdctivitiesmtc accomplish initialization. This 
thesis addresses these problems by providing a framework for 
a Simple system initialization process that can be used with 
a variety of hardware and operating system configurations. 
The approach in this thesis is to make the system 


initialization mechanism appear as much like a normal 
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mmeeercations program as possible, and thus use the operating 
meergem Services to the fullest extent. This apvroach is made 
Bossible by two operating system concepts that are being 
used in Many current operating syStems on large mainframe 
and minicomputers, but have only recently been introduced in 
MeewmicroprocessSor arena. The first is the concept of 
segmented memory. The second is the concept of asynchronous 
processes, including an “idle process so that the svstem 
Mays comes to rest ina state that is easily created and 
@entrolled. These two concepts permit the initialization 
mechanism to avoid the special caseS and ad-hoc methods used 


in so many existing mechanisms. 


mee MOTIVATION 

For several years, the Solid State Laboratory at the 
Naval Postgraduate School has be@€n conducting research in 
the image procesSing area. A relatively recent area of 
research has deen in the development of ‘smart sensors for 
Mueeoile enidance, radar, surveillance, and other image 
processing applications [1]. Current sensor platforms relay 
massive amounts of raw data to ground-based processing 
centers. The smart sensor will provide on-board processing 
of collected data such that only the initial processed image 
and periodic updates need be downlinked to the surface. 
Clearly, a smart sensor will require on-board electronics to 


Mmemthe data processing. 
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Several Naval Postgraduate School theses, under the 
Mmeervyi:si0n Of Professor T. ¥. Tao, have contributed to the 
development of the smart sensor. In 1977, Yehoshua [2] and 
Evenor (3] developed filter designs to improve infrared 
background clutter suppression. In 1978, Hilmers [4] began 
processing real-world infrared images. All the early 
memputer processing was done on an IBM—-36¢ computer system. 
In 1979, Celik [5] developed a Simulation vrogram on a 
Digital Equipment Corporation (DEC) LSI-11 microcomputer in 
an attempt to marry current hardware and software research 
eerorts. Due to its limited primary memory and slow 
Magee ssing Speed, however, the LSI-11 proved inadequate for 
anything but simulation and experimentation. This spawned 
Mereecaonal research in the area of microprocessors and 
meerccomputer architecture. In late 1979, Erenner [6] 
Meesented a multiple microprocessor system design, using 
commercially available, off-the-shelf components, that could 
process the algorithms developed in earlier research ane 
mrso provide real-time, or near real-time, system response. 

Fefore that goal could te reached, however, an cperating 
Maavem waeS réquired to control the operation of the computer 
system. This operating system would provide an interface 
meaewecn the computer hardware and the user. The operating 
system concepts used were baSed on the Multics operating 
system [13,17]. The basic microcomputer operating system 


design was developed by O’Connell and Richardson [1€]. W. ¢. 


1s 





Wasson [7] refined and implemented the basic core, or 
Memneli, of the operating system. The system initialization 
design presented in this tnesis was developed concurrently 


ween the kernel of the operating system. 


C. TERMS EXPLAINED 

In order to facilitate the discussion of sSsyStem 
initializtion, a few terms should be clearly understood. 

1. Operating System 

The operating svstem is that set of program modules 

Mepiin a computer System that govern the utilization of 
computer resources [€]. These resources can be grouped into 
OUT major categories: DEOcesso ns, memory, external 
Input/Output (1/0) devices, and the Secondary Storage that 
Sentains the programs and data. 

eee ry rocess 

This thesis will refer to the word process as the 

internal representation of a computational task. Sach 
process can be uniquely Characterized by its execution point 
Mmame., the State of its processor registers), and its 
address space (viz., the memory accessible to that process). 
Merce only one process can be running on 4 £4physical 
processor at atime, the operating system will multiplex a 
mumber of processés onto each processor. While one process 
is running, the other processes will be waiting their turuas 


to be scheduled and run. But, when viewed in the long term, 
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Eee@me process can be seen es proceeding through its execution 
Meee This is consistent with Saltzer’s definition of a 
process as a program in execution on a pseudo-processor 
[1¢]. 
Oo. Hardware Configuration 
The hardware configuration is defined as that set of 
merdware components, or modules, present in the system. for 
example, processors and memcery modules are parts of the 
hardware configuration. 
4. Software Configuration 
PicmesOttware —GONiteuration 15 made up of the 


= 


processes, system tables, anc system parameters. for 
Beeemole, the number of processes allowed in the system at a 
time would de considered a part of the software 
@onfiguration. 
seo ys tem Configuration 
iMiemsvStenmeconnieuration will te the combination of 
the hardware configuration and the software configuration. 
6. Application 
An application is defined as a program that causes 
mae computer system to perform some useful work. 
7. Virtual Environment 
A key Concept in this thesis is that of the virtual 
meenine Environment. Briefly, virtualization results in a 
hierarchy of levels of abstraction, each dDUuilcing upon the 


MmterricieS provided by the prévious level. If the computer 
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hardware is considered as the lowest level, then the traffic 
Mammen oller, or processor scheduler, could be the next hifher 
level and the applications pregrams could be the highest 
meyer, Thus each level of abstraction runs on the virtual 
machine provided by the lower levels of abstraction, and 
each level becomes a part of the virtual machine seén by 
higher levels. 
8. Core Imaze 

A core image will be described as an exact 
representation of a sequence of instructions and their 
associated data structures exactly as they would &ppear in 
primary memory just prior to execution, but residing on some 
em@ondary storase medium. This term is somewhat of an 
emechronism, since core memory has been replaced oY 
semiconductor memory in most modern computer systems, but it 
@ummereecrTl jtive of the concept. and will be used extensively 
throughout this thesis. 

peo em Initialization Pheses 

In one of tne few publications dealing with system 
initialization, Luniewski iia} views the system 
mortidlization functions with respect to three phases, or 
biome periods. This thesis follows that same approach. 

a. System Generation Time 

The pbootload medium (viz., a core image of the 

operating system) is created at system generation time. This 


mermaliy occurs during a previous session Ons system 
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Operation, or i5 done ona Seperate development computer 
system. 
b. Bootload Time 
Footlioad time is when the lowest level of the 
operating system is actually loaded into the primary memory 
and its system parameters and tables initialized. 
c. Run Time 
The period followinz bootload time, when the 
Operating syStem programs are running normally, is called 
han time. 
1Z@. Multiprogramming 
This term cescribes a system in which two or more 
processes can be in one of several states of execution at 
one time. A process 15 in a state of execution if it has 
been started but has not yet been completed or ferniated by 
an error condition [8]. In this thesis, a process is Said to 
Mee Tunning if it is assigned a physical processor and its 
instructions are being executed. A process is ready if it 
could RiGee out hs NOt “currently assigned a physical 
processor. A process is blocked if it is waiting for some 
event to occur (e.g., an I/0 operation to complete or the 
completion of some action by another process). 
1T. Multiprocessing 
iiVcomnennminpebes tmeat “more thar one processing 


unit is present in the hardware configuration. 
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Multiprocessing is used to achieve greater processing power, 
reliability, and economies of scale. 
ize The Bootload Program 
hee boatload preeram is a simple program written to 
run on bare hardware. The bootload program is tyvically 
stored in read-only memory (ROM), although it may ode 
extended by a bootstrap program read in from a fixed 
imeation in sé€condary storage. [t is used to read the core 
image of the base layer of the operating system fron 
secondary storage, load it into the computer’s primary 
memory, and get the operating svstem running. 
13. The Loader Process 
heemumecetmmnrocess is one of the modules that are 
loaded in with the base layer of the operating system. It is 
emrtar in function to the bootload program, but it is used 
to load the higher layers of the operating syster and the 
application programs. The primary difference is that the 
loader process is used at run time, and maxes use of the 
operating system functions and services provided ty the base 


layer. 


D. GENERAL DISCUSSION 

mimeenerat, the objective of system initialization is to 
get the operating system loaded into primary memory and 
Mmemnineg so that it can provide the support facilities 


Mecessary tO run applications programs. This procedure is 
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carried out in three basic steps that corresponcd to the 
three system initialization phases atove. First of all, the 
bootload program and the core image of the operating sysyem 
are developed. This phase occurs prior to, and somewhat 
independent of, the next two Steps. 

The bootload program is executed in phase two of system 
iemervialization. Its purpose is to read the tase layer of the 
operating system from some secondary storage medium ({e.e2., 
Magnetic tape or disc) and to load the data thet it reads 
into primary memory. The primary memory addresses are either 
merermined by the loader or are encoded in the data. The 
secondary storage medium will contain the operatine system 
Geaqe and data structures. This second phase also involves 
some preprocessing of the core image deta in order that the 
loader may initialize the processor registers and some 
Operatine system data Structures in preperation for running 
the operating system programs. For example, the core image, 
as it exists on secondary storage, contains load addresses 
and some key processor register values. The bootload program 
Mert strin off this information and use it to initialize the 
Meeisters and data Structures aS mentioned above. The 
details of the bootload program will be discussed further in 
Chapter IIIf. 

Meme ast pease Of initialization occurs when Cae 


bootload progam passes control to the first executatile 
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Statement in the operating system code. At this point, the 
operating system will begin its normal execution. 

It is a basic premise of this thesis that actions 
performed during system generation time or run time are 
inherently simpler than the same action performed during the 
bootload phase. Therefore, this thesis takes the position 
mia tne entire system initialization process can be greatly 
Simplified if the core image produced in system generation 
Mmemcas complete as possible, thereby reducing the amount of 
processing required at bdootload time. The justification for 
Mees line of reasoning should become clear in the following 
chapter. 

With the layered approach to system generation provided 
by the virtual environment concent, the most difficult task 
meeea in system initialization is the tootloading of the 
base level of the operating sSsyStem. Once this has been 
accomplished, the initialization process can take advantage 
@eeetme s@€rvices provided ty this base layer to carry out the 
remainder of its activities. As subsequent layers are 
initialized, more and more services become availetle and the 
virtual machine seen dy the system initialization process 


mecomes incredsingly powerful. 


E. HIGH LEVEL LANGUAGE PROGRAMMING 
Since simplicity and general applicability are two goals 


Geeetnis thesis, the design descrited herein is oriented 
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aeemost totally towards a high level programming language 


(PL/M). The motivation for this decision came from several 
sources. Nelson [12] reported a three-to-one increase in 
productivity when a high level language was used instead of 
assembly language. While the standard deviations he reported 
were large, the evidence was overwhelmingly in favor of high 
level languazes. Corbato, Seema nds Clinfene (15) 
merer bute much of the success of the Multics development to 
the use of a high level programming lénguage (PL/1) and the 
interactive debugging that Multics provided. kErooks [14] 
mmees that the increases in oproductivity and debugging 
Speed are overwhelming reasons to use a high level language 
in the design and implementation of systems programs. A high 
level language will also serve as a communication tool for 
anyone who reads the program listing. The logical structure 
Beeetne prorram can be reflected in the listing, and comments 
mee De inserted at will to clarify potentially confusineg 


Mmemcvlons of the program. 


Peo TRUCTURE OF THE THESIS 

RaaieeranS chapter as an introduction, Chapter [1 will 
present an overview of the environment in which this design 
was developed and implemnted. This overview will incude the 
Nhardware used in the project and a odrief look at the 
marosophy used in the development of the operating system. 


Smapter Ill presents the detailed design and proposed 
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implementation. Chapter IV presents the conclusions reached 
mmomne ithe design of this system initialization mechanism, 
and some recommendations for future research that mieht use 


this design 4s a base. 


oe OUMMARY 

This chapter has provided the reader with the objectives 
that mais Paco omeoneS: sLOMaccCOMplish, and “with the 
motivation behind the thesis project. It has introduced the 
meer tO SsSyStem initialization by defining some of the 
terms used in the thesis, anc by presenting a brief general 
Mscussion of the initialization function. Thi¢e chapter has 
also explained the motivation behind the almrost-exclusive 
use of high-level language programming in the development of 


moeeprogerams for this thesis. 
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Il. THE DEVELOPMENT ENVIRONMENT 


Pe OBJECTIVE 

ies Chapuer Will provide a detailed description of the 
Sevironment in which the system initialization mechanism was 
developed. It will include an explanation of the hardware 
used to develop the design for the mechanism, some tasic 
concepts from the operating system it is designed to 
Initialize, and some of tne assumptions made adout the 
multiple microcomputer system and the Smart sensor 


algorithms that the system is designed to run. 


B. HARDWARS 

Pemmcoxsctussed in the background section of Chapter I, 
mmgem it was determined that the single LSI-11 microcomputer 
mom Nandle the processing requirements for a srert sensor 
System, but would not achieve tne desired speeds, the search 
memeeea replacement processor suitable for use in a 
multiple-processor computer system began. The decision was 
made to focus the search on currently available commercial 
hardware, Sic ccuweral sotner “reseach activities were 
Szplorine the use of specialized hardware ohne image 
memG@essing applications. Clock speed, memory size, the 
Mumber of address and data bits, the bus structure, 


documentation, and availability were among the primary 
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memeection criteria POUSTCCTER. The search Peete lly 
Meentified the Dee LSI-11/23, the Intel @@86, the Motorola 
6E@OC, and the Zilog Z8G@e as candidates. 

maenwcacecision to use the Intel 8@56 was finally made, 
Besed upon its performance specificetions, past experience 
meen Other Intel products, and the fact that it was 
Sommercially packaged for multiprocessor applications. The 
Meet nat it was available off-the-shelf and Supported with 
a full product line of support software and perinvneral 
mmeoment also had an impact on the selection. 

The Intel BCE6 is a ea Dit: JetAslOls technolocy 
microprocessor. It has a clock rate of 5 Megahertz (MHz). By 
S@omoining a base address with an offset, it can directly 
access a full Megabyte of primary memory. It is capable of 
meme S-bit and 16-bit Signed or unSigned arithmetic in 
binary or decimal bases, including multiply and divide [15]. 
meracnieves its relatively high speed throveh a combination 
Of its HMOS technology and some architectural advancements. 
mera jor factor in its architecture is tne overlapping of 
Mueeeriction fetch and instruction execution. An inStruction 
Stream byte queue provides for pre-fetching up to six bytes 
Mammeenstructlon during the execution of previously fetched 
instructions. The exact number of instructions prefetched is 
mummrection of the instructions being fetched, since they 


vary in leneth. 
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The one megabyte memory accessible to the 8286 is viewed 
mma eroup Of Segments that are defined by the éenplication. 
A segment can be described as a logical unit of memory that 
may be up to 64 kilotytes long [15]. Note that the segment 
length boundary is not enforced by the hardware. tffective 
address calculations are done with modulo 64k addition, so 
attempts to access past tens toundary Bec uier in 
“wrap-aroun@ to the beginning of the segment. Each segment 
is a set of contiguous locations and is an indeperdent, 
Separately addressable unit. AS Seen in figure II-1, at the 
Mmemaware level segments may be totally disjoint, adiacent, 
Partially overlapped, or fully overlapped. However, the 
integrity of this operating system design demands that two 
Beements. of a process can never overlap. To access a 
particular memory location, it iS necessary to provide the 
base address (viz., in a processor base register) of the 
Segment that contains that location, and the offset from the 
base address to that location. The base address must be an 
meme multiple of 16. To obtain the effective address, given 
the base and offset, the @@&6 performs a left shift of four 
Meeaces On the base address, zero-filling from the low-order 
end. This shifted base register value is the added to the 
maaress offset. This results ina e@-bit effective adcress, 
and hence the one megabyte address space. Figure I[I-2 


represents the address-formation process. 
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mre processor gas direct access to four segments at any 
one time [15]. Their base addresses, or starting locations 
are contained in four segment registers. The Code Segment 
(CS) register points to the tase of the code segment, from 
weich instuctions are fetched. The value contained in the 
Instruction Pointer (IP) register gives the offset, from the 
Mumps, to the next instruction to be executed. The Steck 
Segment (SS) register is a pointer to the base of the stack 
meement. Stack operations are performed on the locations in 
this segment. The Data Seement (DS) register points to the 
current data segment, that is used to maintain program 
variables. There is also available an Extra Segment (ES) 
register, that may point to an additional segment used for 
data storage. 

miocmder major factor in the sélection of the Intel 8286 
was the availability of the Intel iSEC &6/12A single board 
computer. The 86/12A is a complete microcomputer system on 
Mumcmomty 12.0 inch printed circuit board. The version of 
the 86/12A used in this design contains a SME 2 BSGES 
processor, 32K bytes of random-access memory (RAM), @&k tytes 
of electrically progammable read-only memory (2PROM), 
programmable serial and parallel mo interteaces.a 4 
peoerammable interrupt controller, a real-time clock, and 4an 
materface to the Intel Multibus for interconnection to other 
devices [15]. At the hardware level, the 32K bytes of RAM is 


dual-ported. That is, the RAM on one board on 2 
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mebi~computer system PSumcvolemapre= to -adlie ithe other 
processors in that system. The on-board RAM of each €6/12A 
Mmemecectyally seen as two address spaces in a multi-computer 
configuration. Fowever the operating system design does not 
support, mor can it tolerate, a segment havirg two 
gadresses. The dual port feature is used during system 
initialization, but this is a temporary measure, being used 
meee a SUitable bootload program is available in the EPROM. 
The processor on the same board sees its local memory as the 
address space between O@200H and 22¢2@H. The other toards in 
the system see tnat Same RAM as a different address space; 
the exact address range depends on the board on which it 
mesraes and the strapping options employed in the hardware. 
Figure II-3 shows a system diagram of the iSBC 8&6/12A single 
Meard computer. 

The hardware Cent Leura tion of the multiple 
Memeroprocessor system used in this thesis project is shown 
meer oeure JI-4. [ft is housed in an Intel ICS-&¢ chassis, 
which provides the power supplies, cooling fans, and _ the 
Meri ouS Connections. System components include a Mu-Pro 
128K byte error detecting/error correcting KAM board and up 
to six iSBC 86/12A’s. Near-term hardware enhancements 
Mmeeiuae a Multibus interface to a hard disc system for 
on-line secondary storage, and an image display device for 


Smart sensor software development. 
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froeranm aeveryooment was done on an Intel INTELLEC-II 
microcomputer development system (MDS). Since no secondary 
storage was available on the multiple microcomputer systen, 
the MDS system was uSed to Simulate secondary storage for 
the 86/12A’s. A program written for the MDS provides 
communication to one of the multiple microcomputers via a 
wermial—port-to-Serial—port connection. The bootload program 
and the operating system loader view the port just as if it 
were the interface to a secondary storage device. 

As shown in figure [I-4, the two computer systems are 
also connected by an Intel ICE-€6 in-circuit emulator [16]. 
The [CE-86 is used to aid in program development. In this 
application, it is also used to load into the 86/12A’s those 
Meoeerams that will eventually reside in SPROM. Since the 
@6/12A°s do not have direct access to secondary storage via 
the system bus, the run-time loader process that runs on the 
processor connected to the MDS via the serial port link must 
perform the disc I/0 function and make the disc data 
meeriadle to the other loader processors. When the hard disc 
is installed, all the run-time loader processes will tbe 
mMeentical. Until that time, the method described above and 
detailed in the next chapter will be used for system 


Moi. tialization. 
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C. OPERATING SYSTEM BASICS 

The operating system developed for the microcomputer 
System described above waS written by ¥W. J. Wasson (7}] in a 
thesis project that was done concurrently with this thesis. 
ieses many of the concepts develored for the Multics 
system [17], and iS an extension, with a few changes, of the 
distributed operating system concevts presented by O°Connell 
and Richardson [18]. The operating system is intended to 
provide an interface between the user and the hardware such 
maa t the underlying hardware COte surat lone Ss wmace 
Meeeesiole€, or at least of no direct concern, to the user. 
This Sectwlon Cv cCCmELOeS) Geumioeueintended ds a Bbesic 
Mmapeauction to those operating system concepts and 
mechanisms that directly affect system initialization. The 
reader is referred to the thesis by Wasson [7] for 
@gaagitional details. 

im erocessor Multiplexing 

This operating system makes use of the virtual 
memeeronment concept introduced in chapter one. This concept 
provides a layered operating system consisting of several 
levels. At the lowest level is the Inner Traffic Controller, 
whose function iS to multiplex  Saltzer’s “pseudo- 
processors. {10] onto the physical processors present in the 
System. The primary data base used by the Inner Traffic 
Montroller is the Virtual Frocessor Map. A virtual processor 


is defined as a “simulation of a processor using a physical 
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processor to interpret the instructions ‘executeé by the 
Simulated processor. This data structure contains the 
femumemal processor exé€cution state, its scheduling oriority, 
meer process communication information, a cescriptor for its 
address Space (represented by the location of its stack 
peement), and a scheduling flag that signifies that the 
Meese ssor has been sent a virtual preempt interrupt ty some 
Seeer virtual processor. 

fee text level is the Traffic Controller. The Traffic 
Controller serves. to multiplex processes Onto these 
Memeo-processors. The data structure used by the Treffic 
Mmemerolier is called the Active Process Table. This table 
contains the information needed to get a process loaced onto 
a virtual processor and running. 

Wesson also provides a Gate module at the next level 
to simplify the user’s interface to the operating system 
Mmenmetions by providing a single entry point to the lower 
meme is Of the operating system. The programmer intertéces 
with all operating syStem functions by making a “call to 
the gate module using the parameters for the requested 
mmmction aS arguments in the call. 

2. the Process Parameter Block 

In addition to loading the processes into rémory, 
metem initialization must also identify these processes to 
the operating system so that they can be scheduled and run. 


The initialization mechanism described in this thesis uses a 
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Process Parameter Elock to pass DROCceS s Get onit ton 
parameters to the process creation function of the operating 
system. The Process Parameter Block is a per-processor 
Merzice into which each run-time loader process stores 
definition parameters for the process being loaced. When the 
operating system is ready to create [7] the process, it 
extracts the parameters fron the Process Parameter Block. 
Memce process€s are loaded and created one at a time, the 
memory locations in the parameter block can be reused for 
Beck process. As seen in figure II-5, the Process Parameter 
feoek contains values for all the oyprocessor régisters 
associated with a process. Only the CS, IP, and SS register 
memes are of concern in this thesis, but the structure was 
designed to provide easy expansion during later research. 
[mreePriority is used by the scheduling algorithm. The 
Merinity Puce derO. UIMNd a process t0 2 particular 
meocessor. 
3. Interprocess Communication 

Omeenimary importance te any multiprogramming or 
Meeoiprocessing system is inter-processS Communicetion to 
Synchronize cooperating processes and control access to 
shared Reson ces . PAGS operating system uses Ee 
“"Bventcounts and Sequencers mechanism proposed by Kanodia 
and Reed [19]. A summary of this mechanism is provided here, 
Since interprocess communication is vital to the run-time 


loader processes. 
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An evéntcount is 4 system variable that represents a 
O@meass of events that will occur in the syStem. A virtual 
processor can perform three primitive operations on 
eventcounts. It may obtain the current value of an 
eventcount by performing a RZAD of that eventcount. It can 
increment by one the current value of an eventcourt by doing 
Pee ro ADVANCE on that eventcount. Finally, a virtual 
Mmoeessor may await the occurrence of a particular event 
within the class of events associated with an eventcount dy 
doing an ITC AWAIT on that eventcount. This mechanism can be 
mpi y viewed aS uSing a counter to control the virtuél 
processors. However it offers an advantage over the 
traditional semaphore or mechanism. The occurence of an 
event can be broadcast to several virtual processors who 
might be awaiting it. This is more difficult to achieve with 


more traditional interprecess communication schemes. 


D. DEVELOPMENT TOOLS 

As mentioned earlier, all program development was done 
on Bese perate develooument computer system. One major 
advantage of using such a system is the Supuont ive 
environment it provides the programmer. This support is in 
meee torm of the software development utilities available 
from the manufacturer of the development system. In the 
development of the system initialization programs for this 


thesis, the decision was made to take full acvanteage of 
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Meese Utility programs. In addition to the PIL/M-86 compiler, 
three other utility programs, provided by Intel, are used 
Petensively during the syStem generation phase to create the 
core image of the operating system to be loaded during the 
Meotioad phase. These three Intel progrars ére called 
LINK86, LOC&6, and OH86 [20]. They are used to perform the 
functions ‘opae la nkine. loCcatine. and object file 
transformation. ach of these functions is discussed below. 
Appendix A contains annotated sample outputs from the 
development utility programs described in this Section. 
1. Compiling Program Modules 

the  PL/M-E6 compiler (2sele, ia addi t1 Om tO 
translating the high-level language statements into e886 
machine Poster uctrons, —oe.ters four mode options. Tnese 
options let the programmer ASE the degree of 
segmentation to be used. The SMALL option tells the compiler 
to produce only two segments. One Segment combines the code 
sections of all the modules in the program (or program 
Section). The other segment contains all the constant and 
variable data and the stack. This mode provides the greatest 
run-time efficiency, since the Code Segment register and the 
Data Segment register (which in this mode is identical to 
the Stack Segment register) do not change during run-time. 
Mae trade-off is that the total size of each of these 
segments may not exceed 64k bytes, and that there is very 


mmr le memory allocation flexibility. 
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At the other extreme is the LARGE compile mode. In 
this mode, the code section of each module is allocated a 
separate segment. The same is true for the data section of 
each module. The stack sections of all modules are combined 
Meme Orm a Single stack Segment. This mode vnairs up the code 
and data segments of each module and insures that the CS and 
DS registers always contain the values from the same medule. 
In this mode, the total amount of code and data may exceed 
64k bytes, but any one segment is constrained to 64k. 

The COMPACT and MEDIUM modes fall in between the two 
modes discussed, and offer differing degrees of segment 
seperation. The PL/M-86 Compiler Operator’s Manual [21] 
States that all modules in a4 program must be compiled in the 
Same mode. To maintain flexibility and to achieve the finest 
granularity of segment control, the LAPGE mode is used on 
all operating system and application program modules run on 
meemcomputer system used for this thesis project. 

2. Combining Program Modules 

LINK86 is a program used to combine the separately 
developed and compiled program modules into a relocatable 
object module. When these separate modules were compilec, 
mummca@aresses were relative to the beginning of each module. 
LINKES6 accepts these separate modules as input, and produces 
Pemeoucput a single combined module whose addresses are 
relative to the beginning of the linked output module. In so 


doing, it resolves all intermodule references to variables 
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Meameeprocedures. The availability of the linker permits the 
programmer to cevelop small, managable program modules’ that 
can be debugged and maintained separately, and then bound 
into a single module prior to loading. 
eeeassigning Memory Locations 

The LOC8S program takes as input the relocatable 
meect module from the linker and produces as output an 
absolute object module in which all addresses have teen 
converted to physical memory locations. It also produces a 
memory map which reflects the binding performed and a symbol 
table that shows the memory location asSigned to each 
variable, label, and procedure. LOC&S6 also allows the user 
Mmomopecify exactly where in memory he wants the various 
modules of his program to be located. 

pyeeobpTect to Hexadecimal File Conversion 

The output of the locator iS an absolute object file 
feet me input. This object file, as it exists on secondary 
Storage, is a sequence of binary digits. Encoded in this 
sequence of binary digits are all the machine instructions 
moaedata necessary to run the process. Before execution can 
actually take place, however, certain key processor 
registers (viz., the code segment, instruction pointer, and 
Stack segment registers) must be initialized to their proper 
elLues. This is one of the responsibilities of the 
initialization mechanism. These values are contained in the 


Dinary object file. For the equipment used in this thesis, 
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the exact format of the data in these object files was not 
peesented in any documentation available them, tne 
Beerrcacturer. Before the initialization mechanism can 
perform any programmed action on the object files, it must 
Mmmm or be able to ascertain, the file format. Fertunately, 
Meere 1s a file conversion program, called OF&6, which 
Menverts this binary otject file to the hexadecimal ASCII 
Memeety. This program, and the output file it produces, is 
well documented. In an effort to expedite development of the 
initialization mechanism, it was decided to use the OHEG 
bmoeram and convert the object files to ASCII, so that they 
could more easily manipulated. 

There is, however, a storage space trade-off? to 
@emsider. For example, the eigkt-bit tinary value, ¢12¢ 
1111, is read as 4F in hexadecimal. To encode this in ASCII, 
Meer byte is required for the ASCII representétion of the 
4(@211 2170), and one byte iS required for the F(@1@¢ #11@). 
This representation scheme requires twice as much storage in 
meee MDS as the binary form, but because of limited 
documentation it makes the development of the initialization 
mechanism much simpler. The bootstrap program and the loader 
MeocesS in this thesis contain a Simple precedure which 
Mmeverts this ASCII representation back to binary before 
Storing the data, so there is no waste of memory in the 


mertiple microcomputer system. 





teen oSUMPTIONS 

In an effort to expedite work on the algorithms for the 
Smart sensor, several assumptions were made which would 
Simplify the design of the initialization mechanism and the 
operating system. This simplification primarv involves the 
allocation and partial completion of some operating system 
tables used at run time. These tables are used to describe 
to the operating system the set of processes that will te 
running, and the hardware configuration that it will bde 
running on. In a general-user computer system, some of these 
assumptions might not be valid. Future systems programs 
memeroped for the multiple microcomputer system may wish to 
generalize the system initialization mechanism to elimizate 
some of these assumptions. 

The key assumption made is that ene aan tne environment 
mmmevery Static. That is, the set of processes to be run and 
the hardware configuration is known at syStem generation 
time, and remains constant during run time. This assumption 
feeiustitied by the fact that the eé@lgorithms to do the 
processing experiments for the smart sensor system caz be 
Membr tioned into processes before the actual processing is 
done. Therefore, a lot of information about these processes 
can te determined during system generation and passed to the 
bootload and execution phases. For example, all the 
processes that will be executed at run tire can be 


identified at system generation time. 
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Luniewski{11] also states that in order to simplify 
initialization and still permit dynamic reconfiguration [S$], 
some minimal hardware configuration should be assumed by the 
Meeeralization mechanism. This is intuitive. since without 
at least one processor and some amount of primary memory, a 
mempucer can do no useful work. Given this minimal hardware 
Semtrieuration, that is a subset of the largest potential 
hardware configuration, the initialization mechanism could 
employ dynamic reconfiguration to establish the actual 
memaware configuration. In an effort to maintain simplicity, 
this thesis does not attempt to implement dynamic 
reconfiguration. Instead, the hardware configuration assumed 
by the initialization mechanism is the full set of hardware 
present in the system. Since fault-tolerance, which requires 
the capability to dynamically reconfigure the svstem, is a 
imome=term goal of the smart sensor program, continuing 
Mesearch is being carried out to give this initializaticn 
mechanism that capability. 

These assumpmtions permit linking and locating of the 
user’s modules with the same justification as is used for 
the operating system modules -—- they do not change during the 
lifetime of one initialization. Thus they can be treated the 
same as the syStem processes, and their linking and locating 
@m be performed during system generation. While this 
meprodch is contrary to the accepted practice of delaving 


the binding of logical resources (viz., memory segments) to 
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physical resources (viz., memory locations), to enhance 
meevem flexibility, it is fy: Push ted in vols 
maercation by the fact that the environment is statle. 

The iesteeimponrtant item of information that this 
assumption provides is a partial definition (viz., the 
address space) of each process that will be run. This allows 
tne Process Definition Table, shown in figure II-6, to be 
created during the systen generation phase. The information 
in this table includes the process name (uSed to address its 
MDS file), its initial CFU registers, its stack base (used 
mer process creation), its scheduling priority, and its 
processor affinity. Processor affinity implies that the 
Mmeosrammer can state which physical processor his process 
meeee:~=CUtDeE CU ruunSCliéionkw “THIS iS important in the case of a SyStem 
with dissimilar processors. for example, one single board 
computer might be enhanced with a hardware multiplier 
Mrecuit, or a special-purpose I[/0 processor. Also included 
Mermerne initial CS and SS register values. This structure is 
created from information provided by the pregrammer who 
developed each process. 

Another important function that can be done at system 
generation time is the allocation of specific segrents to 
the local on-board memory or to the global shared RAM. 
O°Connell and Richardson [18] present the design of an 
automated decision technique for memory allocation. Their 


design calls for a dynamic memory management scheme. That 
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moe memory allocation and deallocation is a run time 
function. The mechanism proposed in this thesis performs the 
Same memory allocation tasks, but they are performed during 
system generation. The global-vs-local decision is based on 
meee wO-O0yY—~two decision matrix shown in figure I1I-7, and on 
a manually- maintained memory map that keeps track of the 
free and allocated portions of memory. Note that the upper 
Mepthand quadrant of the decision matrix in figure I1I-7 
shows two possible Cnoices cor Poeddi ne sheared, 
non~writeatle segments. 

While memory can be conserved by locating shared data in 
mobal memory to avoid duplication, the choice in this 
design is based upon the desire to keep as many segments as 
pessible Mirenulem=mnocalo: “On-board memory of the using 
PueereesSOr. Since each access to global memory requires 
exclusive use of the system bus for the duration of that 
mereess, ail other processors who might want to access globval 
Memory during this period are forced to wait until the bus 
feet ree. For this reason, accesses to global memory should 
Meeneld to a minimum. This can be accomplished by locating 
all executable (viz., pure) code and as much data as 
mest ole in the local RAM, and using global storage for only 


those variables and data that are shared and writeable. 
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fe SUMMARY 

[ese chapter Mas presented the Environment in which the 
design descrited in this thesis was developed. It has shown 
the hardware involved, an overview of some imoenrvant 
operating system DPimnecioleS ~ a 100K at the software 
development utilities used in system generation, and the 
Mepmigpy2ons made in the thesis end their implications. bith 
teis information as tackeround, the thesis will present, in 
mime ollowing chapter, the design of the initialization 


Mecnanism develcped for this thesis. 
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A. OBJECTIVES 

This chapter will examine the different environments in 
which the three phases of system initialization - system 
Bemeration, bootloading, and run time - take place. This 
Meseussion will unfold the design cof the initialization 
Meedanism developed for this thesis. It will also provide 
the reader some insight into the sequencing of the 
Mmebialization activities anc how the timing of these 
Gemvyities effect the complexity of the initialization 
process. As this discussion progresses, more and more 
references will te made to operating system functions and-° 
Services. The reader desiring more details on the operating 
system, per s¢, should refer to the thesis by Wasson[7] for 


meemore complete explanation. 


B. OVERVIEW 

Chapter I discussed the purpose of system initialization 
moan the three phases of initialization used in this thesis. 
Recall that during the system generation phase, the bootload 
medium, a core image of the base layer of the onpératineg 
System, was created. The other two phases- bootload and run 
meme— perform the loading of this core image as well as the 


remainder of the operating syStem and the application 
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programs from secondary storage into the computer system's 
famary memory. Tre initialization mechanism proposed in 
this thesis involves two severate loading functions. Recall 
thet the bootload program, which runs on the bare hardware, 
is used to load the base layer of the operatine system into 
Mmermary memory and start it running. This program is 
normally ROM reSident so that it may be started by 
activating some hardware Reset or Bootload switch. 

males seconc loading function is part of the distributed 
Operating system, and is loaded into each processor durine 
mimes vOotload phase along with the base laver of the 
Operating svstem. This loader is used during run time to 
load the remainder of the operating system and the 
application programs and to prepare them to be scheduled and 
meme tnis dual~loader approach is common in most existing 
Mmeettdlization schemes, énd will be discussed in detail 
meyer in this chapter. 

merits application, since only one processor has access 
Mmemsecondary storage system on the MDS, the run-time loader 
Mummmtes) «processor is a slightly enhanced version of the 
loader process that runs on the other oprecessors. These 
enhancements include a ‘disc I/0” routine, to allow that 
medder to access the MDS disc information sent to the 86/12A 
serial port, and a procecure to check the Process Definition 


Table to determine when the loddine function for this 
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process is complete. For ease of discussion, this enhanced 


loader will be referred to as the controlling loader. 


C. THE SYSTEM GENERATION SEQUENCE 

Before the anaes begins, however, there is some 
preliminary work to be done that will simplify the remainder 
of the initialization. This work is done during system 
Bemerdtion. As discussed in Chapter [, this thesis proposes 
that actions performed at system generation time or 
Bmosequently at run time are inherently simpler than that 
Same action performed at bootload time. This is due to the 
more suvnportive environment available at system generation 
time, and the overating system services eévailable at run 
time. Compare these to the bare-hardware environment at 
bootload time, and the reasoning tehind this premise becomes 
Clearer. A look at the environment in Ween system 
generation takes place will provide additional justification 
for the proposal. 

Eanc? Svewem Genres adt10n “takes place vrior to the 
bootload and execution phases, it enjoys the Supportive 
environment provided by an existing operating system ard any 
meeitlable utility and library routines. As mentioned in 
Chapter II, the program development for this thesis was 
accomplished an Intel Intellec Microcomputer Development 
System (MDS). The design proposed in this thesis makes 


extensive use of the utility programs available in that 
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environment to accomplish the syStem egeneration tasks. 
System gereration also enjoys the luxury of time. The use of 
boe ISIS-1I operating system in the MDS serves to reduce the 
complexity of the boctload and run time phases. 

Because of the static nature of the image processing 
fopercation for which this initialization scheme was 
designed, the system generation phase can make the 
mermsunrotions regarding the hardware configuration and the 
mature of the application programs discussed in Chapter II. 
These assumptions permit extensive preliminary processing to 
be done in the more comfortable environment of system 
generation. This relieves the later phases, which occur in 
much less supportive environments, of the preparatory 
processing that they would otherwise be required to perform. 

By assuming that the hardware and software 
Sontigurations ere known et at system generation time, that 
miey Will remain constant from one initialization to the 
met, dnd that dynamic reconfiguration is not an issue, all 
memory allocation decisions can be made during system 
peneration. As discussed in Chapter II, the decision as _ to 
whether a segment should be placed in local or global memory 
is based Sie ee MOmOy=bwWO decision matrix. The main 
difference between the Richardson and O’Connell [18] 
allocation scheme and the scheme employed in this thesis is 
that the scheme used here is manual, rather tnan automated. 


This means that that memory allocation is a one-time System 





Peneration requirement rather than on on-going fYrun-time 
function. The O’Connell and Richardson [18] decision matrix 
and memory map are maintained on paper, by the person 
Benerating the system, rather than as data structures 
maintained by the the system initialization mechanisn. 

The simplest way to view system generation is as a 
time-sequence of events, beginning with program design and 
ending with the creation of the load module, or core image 
momebe iioacded. A detailed GCramination of this sequence of 
events will vrovide a foundation for the design choices made 
menmouenout the development of the initialization meckanism 
Meeroribved in this thesis. 

1. Program Desigzn 

The operating system and initialization scheme 
Mmeercped for this project rely on the programmer to design 
his programs to taxe full advantage of the multiprogramming 
and multiprocessing capabilities provided by the hardware 
moe tne operating system. This requires that the programmer 
be somewhat, though not intimately, familiar with the 
operatin system philosophy and the hardware configuration. 
Given this basic knowledge, and the widely-accepted 
technique of structured programming, it is relatively easy 
mmemune programmer to design the required process structure 
into his Drograns: This involves partitioning each 
merrrcation into a group of cooperating processes, and 


mocludine in e@ach process the necessary operating System 
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Batis to Ee verce miLer=nroces s synchronization, and 
explicitly declaring Shared memory Seements LOT 
Sommunication between processes. 

In the development of each process, there are some 
simple “grovnd rules the programmer should follow to 
Simplify memory allocation and enhance the performance of 
the system. First, ali data sharec by processes Should be 
declared to be in segments which are “external” to the 
application procedure [22]. This implies that the variable 
is declared and defined elsewhere. Furthermore, an absolute 
memory address must NEVER be coded inte any application. 
Second, all program code should be reentrant [22]. This 
allows each invocation of a procedure to store its variables 
on the process stack. Thus one invocation will not overwrites 
Meemeevariables used by the previous invocation, as would be 
the case if the variables were stored aS part of the 
meee edure itself. The third ground-rule is imposed to reduce 
the System bus contention problem discussed in Chapter II, 
and merely requires that references te snared, writeable 
variables ance Strmwewurese be held td a minimum. This 
typically involves a single read reference to ‘irput data 
to the process and a single write reference to output the 
data (results). In particular, shared segments should never 
mee wsed for témporary or intermediate results. The fourth 
rule requires that the programmer segregate writeable and 


readable segments whenever possible. This will allow finer 
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feanmularity in the memory allocation process. Finally, the 
programmer must declare the Gate module as an external 
mmmeeanre in Every process to be run. This will resolve all 
meemextertal references to the operating system interface. 
The progremmer is also given the responsibility of 
Merarily jd@ntifying his process to the operating system. 
Recall that a process can be identified by its address space 
mets )6©6CKECUtiOn §6«6point. Therefore, the programmer must 
identify all the Sezments in the process address sSvace and 
must identify which of these segments will be modified 
(written into) by this process. Furthermore, the programmer 
must identify the initial entry point, and any parameters 
Mem roetiis Entry point. This information is actually 
provided to the system operator, who prepares the Process 
Definition Table and makes the memorv allocation decisions 
meea on the full set of initial process identification 
information, as discussed below in the section on memory 
meetocation. 
mercompilation 
After the program has been developed and written, it 
must ve compiled. The compiler translates the high-level 
iemeuaee code into machine language instructions. For this 
application, an additional check is made at system 
memerdtion time to insure that all program modules have been 
Bompiled with the Same mode option. Recall from Chapter II 


that the compiler mode option determines the degree, or 
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Mma rity, Of tne segmentation. This information must be 
Supplied by the programmer, since he is the one who performs 
Toe compilation. 
ee Linking 
The third step in the system generation sequence is 
the linking together of the varicus modules that make up a 
process. Since the programmer knows exactly which modules 
comprise his process, he is in a position to pre~lirk these 
Mpmeees. since each process needs an interface to the 
operating system, each process is also linked to the Gate 
Meee previously described. This implies that each process 
has declared the Gate module as an external procedure. 
4. Memory Allocation 
While the programmer is in the best position to 
compile his modules and link them into individual processes, 
he is mot in a position to know the desree of Segment 
emaring that will take place. Neither is he in a position to 
Know where, in the system memory, other programrers might 
elect to load their processes. Clearly the memory allocation 
decisions must te centralized to avoid chaos. The computer 
System operator, or perhaps a chief programmer, is in the 
Mest position to make these decisions. This thesis will 
@ssume that these decisions are made ty the operator es part 
of the system generation process. 4s mentioned in Chapter 
Il, the glotal<—vs-local decisions are made using a decision 


matrix. 
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Pitierne Geerstoens aS to the specific memory locations to 
allocate for each segment require some information from the 
proerammer. Specifically, the programmer must provide a list 
Geeeetine segments in the address space of his process, the 
length of each segment (which is available from the linker 
output), and whether each segment is writeable or 
non-writeabtle. The identification of segments must be unique 
across all processes in the system to insure that shared 
segments can be vrnambiguously distinguished. Figure III-1 
Shows a suggested Process Information Form which might be 
used ae Standardize the content and format of this 
Mmerormation. The form contains one entry for each segment in 
Mmeeweadcress space, anc indicates which of the above 
Meerboures apply. The programmer is also asked to identify 
which other processes will share each Segment. This is used 
only to ene ss GAeci error mpeostble design errors in 
Mmeergrocess communication. The per-process Tse aso 
Mmeeruces the initial parameters, tne process priority, and 
Meeeree>s5Or affinity information that the operator needs to 
build the Process Definition Table used by the bootload 
Program and thé run-time loader processes. This information 
=orm is provided for Gaichumanolt Cation process and 
(separately) for the operating system kernel for each 
Maysical processor. The kernel includes only one per-process 
data Segment: the kernel stack. Since the kernel is linked 


only once for each processor, the operator must create the 
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precios INFORMATION LIST 
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Beeorespondine Stack for each process. AS discussed by Wasson 
{7], the kernel stack must be allocated as a logical 
extension of, and at a lower address than, the stack segment 
mor C€ach process. 

ic(eviivnennmhs process intOrmation list anc the 
Allocation cecision matrix, the operator is now prevared_ to 
Meme tue actual allocations of specific memory locations to 
Segments. Since he is, in effect, the Memory Manager process 
described by O°Connell and Richardson [18], he will maintain 
moemoystem Memory Maps, for both local and global RAM, which 
reflect the status of the system memory. As shown in fivrure 
Til-2, the memory mép contains the tase address and length 
of each named segment and the base address of the free or 
unallocated areas of memory. The memory map is completed as 
meoorted 1iSt to aid in detecting allocation errors made by 
mies Operator. The local and global memory in the system is 
Seerocated separately; only shared, writeatle segments ére 
peeboceted to eglobal memory. A useful guideline is to 
A@€llocate ali local kernel sefments at addresses below the 
pep ications SO that applications StackS can never 
“overflow into the xernel. Pecall from above that the 
operator must add a kernel stack seement for each process. 
It is also up to the operator to avoid “checkerboarding , or 
Mmrerpmentation, the condition in which many small free areas 
exist whose combined sizes are large enough to contain a 


Z-arewewmomrenone are large Gnough alone. This condition can 
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usually be avoided by careful allocation, but it may also 
mivoive some trial-and-error to obtain a proper fit. 
Bee Locating 

Once all the allocations decisions have been made, 
the actual assignment of phvsical memory locations is made 
Pees the locator utility program, LOC&6. The system 
Meematrore passes the dallocation decisions made for each 
process to LOC@6 aS parameters. TheSe parameters indicate to 
Mmeemtocator the base address of each segment, including the 
meme) Stack, in the process address space. 

the “operetime instructions for LOC&86 contain the 
mopnons and parameters required to control memory allocation 
{22}. The-output from the locator is the binary core image 
Seeeune process that was input to it. This image is complete 
with load addresses for the code and data in the process, as 
well as the CS and SE register values necessary to start the 
MeeeeesS running. The locator is run once fOr each 
application Paoeessemeancaem=once (per CPU “te locate the 
Merri buted opéreting system kernel thet is available 
throueh the Gate to all processes. 

Sari le Conversion 

As discussed above, the memory management function 
was not automated due to the lack of documentation 
Mmeceornimoesoinary “object files. For the same reason, the 
Peet toad program and the run-time loader processes were 


Mmeerenreaq sto redd the ASCII files output by the file 
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Mmemversion program, OH8G. The OH86G output format is well 
documented [22]. So the last step in the system generation 
meoeess iS to run OF&6, once per located process and CPU 
moemei, t0 transform the binary object file into the ASCII 
format expected by the loading processes. A skeletal example 
Poeecrne Output produced by CHESS is contained in Apnendix A. 
7. System Generation Summary 

Sefore proceecing into a discussion of the bootload 
phase and the environment in which the bootload program 
Guess, 2t Will be beneficial to pause and examine exactly 
what was accomplished during system genération, and exactly 
where the initialization process Stands when System 
Peneration has teen completed. This thesis views system 
generation as a time-sequeéence of events that bezins during 
meoeram design, and proceeds through compilation, linking, 
Memory aglilocation, locating, and file conversion. At this 
Moent, the ASCII representation of the core image of each 
[Mmemeess to De loaded has been created and stored es a file 
on the secondary storage (viz., floppy disc) in the MDS. The 
@isc alse contains two other files: the bootstrap program 
eam tne kernel] base with tne run-time loader process. A 
Praphic representation of the disc, as it appears at the end 
of system generation time, is shown in figure III-3. Note 
that for each process the loader needs the disc address 
(i.e. track number and sector number) of the target file. In 


the MDS-based loader, this address is the actual 
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filename, Since the filename is used by the ISIS-Il 
operating system disc routines on the MDS. The filename is 
Soiemeor tne items of information available to the loader 


Bmgeee so in the Process Definition Table. 


Meeete® BOOTLOAD FHASS 

When it is desired to initialize the svstem and run the 
application programs, the bootload phase begins. In most 
Bemourver systems, the bootload program is invoked by 
activating 2 ‘reset or  dootload switch. This causes a 
momo to the first instruction of the bootload program, which 
memecontained in Beg Me, Peer uae proposed Rawe ware 
enhancements have been made, and the complete operating 
system has been developed, the bootload program for this 
System will te placed on EPROM, and will be invoked in this 
Same manner. This section will discuss the sequence of 
Mertialization actions that take place upon invoking this 
ROM—-residert bootload pregram. 

Pike System generation, the bootload phase can te viewed 
as a time-sequence of activities, beginning when the 
Meeouload SWitch is pressed, and Ending when the operating 
System kernel is running. When the bvootload switch in the 
Mortiple microcomputer system is depressed, it causes a 
marawdre interrupt to occur in all the processors in the 
System. the interrupt handler for the bootload interrupt is 


Meee OM—-resident bootload program in each processor. 





1. Invexing the POM—resident Bootloeder 

the SOg@mioa@mmoutLine 15°94¢ Small, very Simple program 
mmemeesoerTves three basic functions. First of all, it must 
determine which CPU in the system will be the “3o0otload 
CPU. The Bootload CFU will serve aS the maSter or 
Somesolling C>! throughout the bootload and run-time loading 
phases. While the »bootload oprogrems in all CPU’s are 
identical, the Bootload CPY will execute some sequences of 
[meme tulons that the other processors will not. When the 
Dootload vrograms begin execution, each one will attempt to 
read the same variable in global memory. This variable will 
Dev initialized by the EPROM programs to a predetermined 
value. AS mentioned in the section on memory ellocation, 
maees> tO flotal mémory requires that a processor have 
exclusive use of the system bus. There is a built-in system 
bus lock that can be set @s soon as a processor gets 
Mrmr ol of the bus. This lock will be used to resolve the 
memr iret of multiple simultaneous access attempts. The 
Mere oor that first sets control of the bus will become the 
EBEootload CPU. This processor will then alter the value of 
male £lobal variable. When the bus lock is turned off, and 
euner processors are able, in turn, to access the variable, 
they will see that the variable has been altered, and enter 
dewait loop, awaiting further instructions from the Bootload 
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Pomme THe tne —phOerammer to specify which physical 
processor he wants his processes to run on (i.e., the 
affinity of the process), there must be some way to identify 
these processors. maysically, PicMEPEOCeSSOrS Can be 
meemriried by some unique serial number or identification 
mamoemem bis type of identification is inconvenient for the 
operating system because the physical processors can be 
Mmemovec and replaced for maintenance, testing, and for 
various other reasons. Therefore, the initialization scheme 
meeds <e¢ method of assigning logical CPU numters to the 
Meyoical processors currently in the sSyster. This can te 


Gone in @ manner similar to determining the Bootload CFU. 3 


nt 


memyention, this scheme assigns logical CPU number ¢@ to the 
moor load CPU. The Bootload CPU enters itsS Serial number, 
mech 6UiSlh6CContained in its EPROM, into the first entry of a 
global structure called the CPUSTABLE. The Footloéd CFU then 
sets a global variatle called LOGICALSCPUSNUM equal to 1, 
mem unlocks the dlock which has been associated with that 
variable. The other processors will row race to access 
LOGICALSCPUSNUM. The winner of the race will set the lock, 
pees itS serial number into the second entry in the 
CPUSTABIE, increment LOGICALSCPUSNUM3ER, and then unlock the 
[meee iris process will continue until all the physical 
processors have been assigned a logical CFU number. The 
Bootload CPU will know how many CPU’s there are in the 


eonfieuration and that all processors in the system have 
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Gaemmassigned a logical number after some fixed time period 
(a few milliseconds) has elapsed. In addition to the two CPU 
numbers in the CPUSTABLE, each processor also hes a 
Meeeeirox ° a location uSed for a primitive method of 
meperprocessor communication with the Bootload CPU. 
2. Accomodating the Initial Fardware 

AS previously discussed, the hardware configuration 
fees not presently include online secondary storage, and the 
decision was made not to write the bootload into EPROM until 
the development was complete. Some temporary alterations 
were made in the initialization mechanism to permit the 
eevlopoment to proceed with Bas Ot hardware 
mer ieurdtion. The use of the MDS to simulate secondary 
Storage was mentioned previously. The tootstrap proeram 


Meaas Gata from the serial port of one of th Be7 leas 
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emele—-board computers. A program was written for the MIS 
meemeereacsS the hexadecimal object files from floppy disc and 
meets tne hexadecimal data to the MDS serial port. There 
is a cable connecting the two serial ports. The cable is 
made to allow 2 primitive sort of vrotocol tetween the two 
metems via the clear to send and request to send status 
meres (25). This constrains the loading funtion to having 
Meeress to Secondary storage from only one processor, rather 
noanm irom any processor on the statem bus. To simulate the 
meee nce or an BPROM bootlodad program, the ICE-86 in-circuit 


emulator was used to load the bootload program into &RA™M. 
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meme ine —cudl—port memory cepability, the ICE-86 can load 
the bootload into each processor’s local memory. The ICE-&6 
was alsc used to alter the interrupt vector in each CPU so 
meray the preempt interrupt would transfer to the bootload 
Eeoeram., finally, the processor connected to the MDS was 
meee Slightly @iffereaent version of the tootload program 
meats Sterts its execution by sending ae one CU Ute re teTTupy. tO 
fmmmertaer processors, simulating the bootload switch. 
Ser Loading the Bootstrap Proeram 

With these preliminaries out of the way, the 
Boot load CPU Sees vente oeumect tual  bvoolbstrap loading 
memetion. This load involves the first access to disc by the 
Mmmetdalization mechanism. Since the bootload program is 
Meeeeii-reSident, Simplicity is a primary concern. For that 
reason, the tootloac program will merelv read from ae fixed 
meme >> On eadisc, and lodd the data into a fixed area of 
global memory. For the same reason, only the Eootload CPU 
femeemaccess the disc. This simplifies the tootloéd proerams 
by eliminating the need for a complex synchronization method 
Mmorcellow the processors to share the disc. The bootload 
program on the Bootload CPU will merely read a Single disc 
mecord, ang load that record into a pre-specified ealobal 
temomm cutter. Note that this disc record is alreedy in 
executable format (viz., not a hexadecimal file). It will 
mime transfer control, with an unconditional jump, to the 


meovconect thestirst syte in the buffer. This will trensfer 
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meomnrol from the EPROM bootload program in the Bootload CPU 
Meee) UOOLStrap program just reéad in from disc. Figure 
IfI-4 shows the contents of the System memory after the 
meoeload program has been run. 
4, Executing the Bootstranv Program 

Tne PecmnOtmmaatdemyust redd in  Cortains the 
bootstrap oroeram developed during system generation. Recall 
mmeieetois program is designed to load the base layer 
(kernel) of the operating system from disSc into primary 
memory. Since each processor’s local memory will contair 
memes Of this kernel, each processor will need to execute 
the hootstrap program to load its kernel. For simplicity, 
all processors will share the same bootstrap program code, 
Peat will be located in global RAM. The Footload CPU (at 
mess point executing the bootstrap oprecgram) will do the 
met Gisc read for all processors. This is consistent with 
Baeemethod used te accomodate the the initial hardware 
Configuration as discussed above. The Bootload CPU will lead 
the hexadecimal file containing the base layer of the Kernel 
meno, a 2lobal memory buffer, leaving it in the hexadecimal 
Mmmemet. ©ne Bootload CPU, since it is already running, will 
meen be the first processor to load the kernel into its 
Mocai memory. The bootstrap program includes functions to 
read the hexadecimal object file (the kernel) from the 
global RAM buffer, convert the data EO Ais binary 


(executable) representation, and load it at the addresses 
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Specified in the hexadecimal file. Recall that this load 
address for each segment in the kernel is made up of the 
Segment base address in the segrent base address record and 
the load address offset contained in the data record itself. 

Memo wereprocessoOns @re still executing the EPROM 
bootload program, waiting to be Signalled by the Eootload 
CPU via their meilboxes . The Bootload CPU now signals each 
Meer turn to load its kernel, and then waits for a signal 
that the CPY has done so. Note that before signalling, the 
Bootload CPU insvres that the target CPU’s kernel is in the 
Perobad buffer— either read in from disc or still present 
Meemeone loading of a4 previous CPU. When signaled by the 
Bootload CPU, each CPU transfers (jumps) from the EPROM 
meoustrap program to the global RAM bootstrap program. It 
then executes the routine to read the file (the kernel) from 
the Oat er’, convert the data Dee “VO 1tS- Dina ry 
memopesentation, and load it into tne addresses specified in 
mmemrsCIl file. Since the idéntity of the kernel hexadecimal 
file is well defined, and since the number of CPU’s is known 
(7. , available from tae) GP Table), this bootioad 
mmocedure iS relatively Simple. Recall that Simplicity is a 
primary goal during the hbootload phase since the environment 
ioe Oniy the bare hardware. AS each processor completes its 
moor boading task, it will perform an unconditicnal jump to 
miewrtinrst location in its kernel (now in executable form). 


The Bootload CPU will jump to the kernel after all other 
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CPU’s have finished their bootloading task and signalled 
moees fact to the Bootload CPU. 

cmp leslimuldte a preempt interrupt in the 
Mmomer Traffic Controller interrupt handler {7}. The jump is 
memmeoespecia] @€ntry point in the interrupt handler rovtine 
meee. S used Only for initialization. This entry point saves 
meeworocessor register values, which include the logical and 
mmpercal CPU numbers, that must be saved for later use by 
M@@eminner Traffic Controller Scheduler. The entry into the 
meer Traffic Controller marks the end of the bootload phase 
mom che transition into the run time phase. At this point, 
abl processors are executing in the kernel. The tootstrap 
mmeeram iS no longer needed, and will be overwritten. The 
System memory at the end of the bootstrap sequence is 


configured as shown in figure III-5. 


fee eUN TIME 
The loading performed at run time is conceptually quite 


5 


mimelar to the vootloadineg discussed in the previous 
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section. One difference between the two phases is that the 
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run time loading involves all processes that are to be run. 
But the main difference is that the “Bootload function is 
done by run time loader processes that run on the virtual 
Mmocessor provided by the kernel. This implies that the 
instruction set now includes the operating system primitives 


provided by the kernel (e.g. ITC_ADVANCE, ITC_AWAIT, and 
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Create Process). This provides a much more supportive 
emeeeronment than the bare hardware of the bootload phase. 
1. Invoking the Loader Processes 

HomUnderstane Cxactly whet Peopvets weens, re Dootload 
Meestanm jumps to the preempt handler in the kernel, it will 
Memeoenericial to review just what is in the kernel base, and 
how the contents of the kernel go about performing the 
remainder of the loéding activities. 

There are actually two processes in the kernel base. 
Meemeerirst is the idle virtual processor. Recall that this 
“processor. is invoxed when there is no other vwseful work 
available to be run on a obhysical processor. The other 
Mememereerrecess is the run time loader process~ just a 
modified version of the O’Connell and Richardson memory 
manager process [{18]. All kernel segments are included in 
the address space of both these kernel processes. 

The Virtual Processor Map (VPM) in the Inner Traffic 
meee rolier was initialized during syStem desien to reflect 
that the idle virtual processor is running or each CPU. 
The memory manager (i.e. loader) is initialized in the ready 
mene anc with a high priority. All other virtual processors 
mee’ in the idle stéte. 

The Traffic Controller’s Active Process Table (APT) 


meernitadalized with NO applications processes. All virtual 
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feeereessors visible to the Traffic Controller are shown to be 
Bunning an idle process. 

Because of this initial state created during system 
generation, the jump to the Inner Traffic Controller at the 
emomeot the bootload phase a@ppeérs to the kernel as a preempt 
Mmoevertrupt of the idle virtual processor. This preempt causes 
Meemaiener priority loader process to be scheduled and run 
mameacn pnysical processor. 

These loader pROcesces cigiendye ere | Process 
Definition Table in their address space as an external data 
Sesment shared by all loader processes. This tatle is the 
primary data base used to drive the remainder of the loading 
Pommction. 

Pe beading the Application Frocesses 

Now that the op@rating system kernel is running on 
Gach physical processor, it can be used to load the 
mepeication processes from disc. Since each application 
MeecesS Exists as a hexadecimal object file on the disc, and 
Since the loader processes have a complete description of 
Beet application process in their address spaces (viz., the 
Process Definition Table), the remainder of the loading 
tasks are relatively straightforward. This will involve 
Beacing @€ach application process from the disc, placing it, 
in executable (i.e. binary), form at the appropriate 


Mecation in the system memory, identifying the process to 





the kernel, and finally, causing the kernel to schedule and 
execute the application processes. 
mae rootlioagd CPU still serves as the system master, and 
eee makes all disc I/0 requests. Since their register 
feeees, inclucineg their serial numbers and logical CPU 
mempers, were passed to them at the beginning of run time, 
each processor can determine whether or not it is the 
femeoad «€6CPY (i.e., is its logical CPU number @?). If it is 
feiyetne loader process will do an ITC_AWAIT, until it is 
Signalled to proceed (via an ITC ADVANCE) by the Rootload 
Mmeeeerde sequence of operations performed at run time call 
mor the Bootload FU to read the first non-kernel 
memeaecimal object file from tne disc and to store it in the 
mepobal HAM buffer. The Pootload CPU then checks the Affinity 
in the Process Definition Table to determine which physical 
Mmaeessor the process is intended to run on. It will then do 
am ITC ADVANCE on the appropriate eventcount for the loader 
process in that CPU. Note that there is the special case of 
meoplication processes being loaded on the Bootload CFU. In 
mes case, the signalling will be sliehtly different. LE2ut 
mors Will require only a minor addition to the loader 
program. 
The designated orocessor’s loader process will load 
and convert the hexadecimal object file as described in the 
Mmeevious section. in addition, it will extract from the 


Memececimal object file the CS and IF register values. It 
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will enter these values into this loader process’s Process 
Parameter EBlock, along with the SS register value from the 
Emoeess LPefinition Table. The loader process then calls the 
kernel @raffic Controller procedure Create Process , 
passing the address of the Process Parameter Block as. an 
DME creale Process makes the necessary entries in the 
Merve Frocess Table to describe the just-loaded process, 
and initializes the Momo mond er ee: Or tails. process. 
Meee rrocess then returns into the loader process from 
Teme it wes called. The loader process will, in turn, 
notify the Bootload CPU that it has finished, and the 
meorrcac CPI) will read in the hexadecimal object file for 
mmetvner process. 
eeeimitiating Application Process Erecution 
pmseesequence Of events 1S repeated until the loader 
fmoeess On the Bootioad Cru finds a null entry in the 
meocess Lefinition Table, which sienifies that all processes 
have heen loaded and created. This means that all system 
Mmamerahizgation functions— system generation, bootloadineg, 
Bem run-time loading- are completec, and all epplication 
Beacesses are created, loéded on Te taenets respective 
moc’ ssOrs, and in the ready state. The only thing required 


fMeeemcor tee 2ootloced CPU to call the ITC _S& 


ta 


PREaMpn 


procedure for each virtual processor Known to the Traffic 


meomrolleér and then do an ITC_AWAIT. This will cause the 
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memes scheduling functions to run the highest priority 


process that is ready to be run on each processor. 


fee MARY 

In this chapter, the entire sequence of events required 
for initialization of a multiple microcomputer system have 
teemeeexamined. Hach of the initialization phases - system 
generation, hootloading, and run time - and the environments 
eweiren they occur, have been analyzed. This analysis was 
intended to show the reader how initialization can, indeed, 
Memoomolified hy a careful sequencing of initialization 


mevivities. 
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Meeeoannt ENDOCONCLUSIONS 


Pee SUMMARY 

Meme 20d! Of this thesis has been to develop a system 
Meera lization mechanism for the Intel 8@&6-based multiple 
ipeemocomputer system to be used by the Solid State 
Laboratory at the Naval PoSteraduate School for ‘smart 
sensor research. A secondary goal, from the cutset, has 
Memmeto present a system initialization design philosophy 
meee would help fill a void in current comouter science 
Meperdture. This design philosophy asserts that the issues 
of syster generation and bootstrap loading deserve a level 
memconsideration equal to, and concurrent with, operating 
Peeerenm issues. The basic premise of the thesis is that 
Simplification leads to a more versatile and robust design 
mmo uooegquentiv, to a system initialization mechanism that 
is easily understood and readily adaptable to a variety of 
Mmeraware and operéting system configurations. 

The simplification in this design approach is achieved 
eeeevw~O means. The first is a core-image criven loader. This 
meme involves creating a copy of the base layer of the 
operating system as it should appear in prirary memory 
mumealately prior to @xecution. This core image is then 


Stored on some secondary storage medium. When it is desired 
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to initialize the system, this core image is merely loaded 
maemo Orimeary memory and control is passed to the first 
mastruction. 

Tae other, and protebly more meaningful, means of 
Seamoplification is to carefully Seauence the required 
Meo itd lization activities such that each is perfcrmed in the 
meee SUppOrtive environment availatie. This Pras ers 
mometional) complexity to a phase of initialization that 
emmoys the most operating system and utility program 
Support, and removes possible complexity from the bare 
manaware Environment of the bootload program. Since the most 
Supportive environment in this application is 4&vailetie at 
System generaticn time, tne goal was to accomplish as many 
Meera liZation activities és possible during this phase. 
With the assumptions (based on the application for which the 
system was designec) made at system generation time, this 
Mmeiceweas dble to fully exploit this most Supportive 
emvironment. In so doing, the generation of the corplete 
core image and all memory allocation were éccomplished 
Meuring system zereration. As the core image of each process 
momeredted, the identity of the vrocess (viz., its address 
Space and execution point) were encoded into the image. Thus 
everv process Tw the system Could be completely 
Saebacterized with information contained in its core image. 
Mais Cdpability creates a compilation-indcependence that is 


important to a general purpose initialization mechanism. 
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iiewesysteme ane tialization scheme designed for this 
mies maxes e@xtensive use of the operating system kernel 
primitives avaiable at run time. In Ratt veu lar, the 
ITC_ADVANCE and TEC ACAI T primitives are ocd for 
maperprocesS communication durine the loadine Oe the 
feed tion processes, and the Create Process function is 


meea to identify the application processes to the kernel. 


B. FOLLOW-ON WORK 

This thesis has scratched the surface of an extremely 
interestins and challenging research area. Eut in developing 
Mee initialization mechanism discussed here, it drought to 
mmerrt many follow-on research ideas. Naturally, the first 
Pol! Ow-on work Ssnoul¢e concentrate on compnletine the 
mmeeementation of the design presented in this thesis. The 
design and implementation should then be extended to 
Supoemate as many of tne manual functions as possible. This 
meoulg include complete automation of ithe linxine and 
mecating processes, possible elimination of the Pile 
conversion program, and automated memory allccation 45 
discussed by O’Connell and Richaréson [18]. This would 
meerae  nrogrammatic creation or the Frocess Definition 
meple, initial memory MAD, and the other syster 
mmevidlizgdation data Structures. This effort will require 
mero. onal documentation from the Intel Corporation on the 


development tools and file formats discussed in Chavter II. 
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Hecatl that this thesis made several assumptions to 
Peamptity and expedite the development process. Near-term 
research efforts might attempt to eliminate sore cf these 
assumptions, particularly those about the static nature of 
the run-time environment. This would result in a more 
generally applicable mechanism that would te less dependent 
meee DriOfa knowledge about the system configuration. In 
Omeer to achieve this generality, it will be necessary to 
Geememate most of the functions that are done manvally in 
this thesis, particularly the memory allocation. The design 
Sec ois initialization mechanism is compatible with the 
memory allocation scheme designed by O”°Connell and 
Richardson, and should accept such a run-time memory 
eemeoeation function without major alterations. 

Of immediate concern to the smart sensor research 
femieet Should be the integration of the hard disc sutsystem 
into the hardware configuration. The availability of on-line 
meamemeany storage would permit further simplification of the 
initialization mechanism, and remove the need for the 
"controlling loader. 

The most challensing research area, however, iS dynamic 
reconfiguration and its subsequent bdenefit- fault tolerance. 
Meese are State~of-the-art issues that are also long term 
goals of the smart sensor program. They are also almost 


mandatory for 4a viable, operational smart sensor platform. 
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G. CONCLUSIONS 

meee workesaone In this thesis Ras shown the feasibility 
of developing a Simple, versatile syStem initialization 
mechanism based on a core image approach and the careful 
mmemcine® Of initialization activities. The design proposed 
mmeeiis thesis has not been fully tested, but sufficient 
maemeroms were implemented to Support the basic concepts 
proposed. The experience with the system thus far has shown 
Mmomeene concepts are not difficult to put into practices, 
meaetnat they do result in a Simple, eaSy to understand 
mechanism for loading and starting a process ona tare 
Mememine. The design proposals developed in this thesis 
eeomic prove beneficial to future initialization development 
MeeeortS, even where the hardware and operating system are 
different. 

miemyiesis has also confirmed the value of an operating 
system with explicit segments and processes, and has shown 
Mowesuch adn operating system structure can be exploited to 
een t icantly Simplify the initialization mechanism. as this 
structure for microcomputer operating systems beccmes more 
widely implemented, the methods used in this thesis can te 
widely applied to simplify tne entire system initialization 


process. 
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Poe ULI niTY PROGRAM OUTPUT 


Memo eJECTIVES 

wees doppendix is provided to further acquaint the reader 
with the Intel software development utility programs used in 
mmeeeeunesis. ach program and its pertinent parameters and 
Options Will be explained, and a Sample output will be 
provided. While tnese programs are Intel rcroducts, and are 
mererened Specifically for the Intellec MIS with the IS1S-II 
operating system, they are representative of proeerams 
meeveaea with other computer systems. The séemple outputs at 
mmemeeend Of this appendix are baSed on a very Simple PL/M-&6 
program, written only to demonstrate the development utility 
Mmoerams. The source code for tne sample program is skown in 


feeeure A-~1. 


Eee FL/M-86 COMPILER 

Pememettuioned in Chapter Ii, the FL/M-&6 Compiler 
translates the PIL/M-86 source statements into S¢8E machine 
[eemertuctions. The MODS control in the comrand A 3c 
determines the degree of segmentation. In the semple program 
@omersation in figvre A-2, the CODE control was used to 
cause the compiler to list the &ZS6 rachine code 


instructions generated “or each PL/M-86 instruction. Note 
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mace tae ilengeths of all the segments n»produced ty the 


momprier are listed at the end of the output. 


GeelHE LINKSE PROGRAM 

Mme linzer program, as discussed in Chapter II, combines 
the various program modules that make up 4 process and 
Mmerorves any external references. At the sére tire, it 
adjusts the relative addresses in the mecdule se that they 
are all relative to the teginnine of the output module. The 
meee LINKES output listine in figure A-f shows the list of 


segments produced for the samvle program ty the Irtel 


feo rer, 


D. THEE LOCE6G PROGRAM 

macmerocatOr proerdm 15 used to assign physical memory 
addresses to the relative addresses in the linker output 
module. L10C86 vrovides several diagnostic and cutput format 
@emierois {2¢). Diagnostic information includes a symtol 
table anda complete memory map, showing tne results of the 
meermnoresunctLion. This information is s€nt to a4 printable 
Geoe rile urless otherwise Snecified. Cutput module controls 
are used to control the content of the output module, the 
O@eoer Of the segments in the module, and the assignment of 
Biaysacal memory locations to the segments. The controls of 


Meomary Concern here are the ADDRESSES and SEGMENTS 





controls. As seen in figure A-4, these controls assign a 
base address to @€ach Segment in the process. 

The Guedes control on interest during system 
Mmomera!)Zation is the SECSIZE control. It is usSed to Specify 
Meemoize of one or more segments in the output module. This 
Control is used during system generation to build the xernel 
stack frame discussec in Chapter IIIf. 

mages sample LOCEG output in figure A-4 includes the 
process s symbol table and memory map. For illustrative 
Mumepoeses, the SEGSIZE control was used to add 2¢5 tvtes to 


the size of the stack Segment. 


teres OHS6 POGRAM 

meet imeal utility pvreogram used durine System eeneration 
femeeone file conversion program, OHSE. Recall that this 
program translates the binary object file (for which very 
little documentation is available) into an ASCII hexadecimal 
object file (which is very well documented). The sample 
meeput from OH&6 is shown in figure A-5. The blenk spaces 
and line numbers were added to improve readability, anc do 
meeoceur in the actual output file. 

Bacn hexadecimal file produced by OF&6 is made up of 
mour diprerent Beeera  tyadeswe nese = record types are 


explained below. 
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meet cecoOramiyper oe 15 the Data Record. These reccrds 


Sempein the actual program code and data that meke up each 
process. 

ee Record Type €i is the End-of—File Record. 

cs. Record Type @2 is the Extended Address Record. This 
meegman Specifies the segment tase address for the type @¢€ 
Meeoras that immediately follow it. For example, the type 2 
memord in line 11 of figure A-5 contains the segment tase 
address (@€1@@H) for the type @¢ records in lines 12 through 
a 

meernecord Type ¢€5 is the Start Address Record. It 
Specifies the Code Segment and Instruction Pointer register 
meee s for the first inStruction in the Code Segment. In the 
example, the CS register value is @100H, and the IP register 
mere 1S COGEF. The locations from the address specified in 
LOCe86 (1@@@F) to the address specified in the Start Address 
Record (1@@8H) are used by the comviler to store the 
addresses of external data Ssegmrents, and the DS and SP 
register values (see lines @i through ?4). 

Bach of the records in the hexadeciral object file 
Mmomoists of several fields. These fields, and their effect 
on the loading function is explained below. 

bee record Marx Wield is used as a record celimiter. 
@reoe uses an ASCII colon (@3AH) to Signify the teginnine of 


each record. 
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meine necord benetno Field contains two ASCII digits 
Bea t specify the length, in bytes, of the data or 
mmeormation contained in the record. 

©. The Load Address Field contains the address offsst 
from the segment tase address (in the type @2 record) for 
miemrrrst data byte in the record. Note that only type &2 
records have load addresses other than 2@0@. Recall from 
Chapter II that there is no boundary check méde when 
a@aqdqressing into a segment. Tne exact load address fora 


memerctiiar data byte can be calculated es follows: 
EFF. ADDR. = BASE ADDRESS + [(DRLA + DRI) MODULO 64K] 


Where DRLA is the Data Record Load Address, and TPI is the 
[eee index Within the Data Hecord. 

4. The FPecord Type Field specifies the type cf the 
mereord, as described above. 

5. The Data Field contains the actual data to he 
memivertec to bindry and loaded into primary memory. This 1s 
a variable length field that may te from 2 to 1@H bvdytes 
mone . 

6. The Checksum Field is used for error detection in the 
mead end translating process. It contains the twos 


Somplement of the @-bit sum of the bytes that result fror 


@enmverting the ASCII bytes back into binary. 





SUMMARY 

This appendix was intended to acquaint the user with 
MemencetaiiS concerning the software development utility 
programs used to develop the system generation mechanism 
Mescrived in this thesis. It hes provided 4a very simple 
PL/M-86 program and the output from each of the development 
Mprtities. The reader desiring additional information atout 
these programs should Reson mevo ure .MCS-e¢ . Software 
Meepelropment Utilities Operating Instructions for ISIS-II 


Users [2]. 
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SOURCE LISTING 


[PRI PE HERE FR HEHE He BET AE HS AS HHS BE ARE HE AR IS OK HE BES TK SNE HS OE BK HE I BE AER SE aS NE ONE 2 BE ae a ag ae ae ae aa 
/# 
a Sample Program to demonstrate the software 
ye Sevelempnenr utility programs used during 
he system generation. This program simply 
[* inerements a global array element nine 
a times and then prints the result on the 
a terminal screen. 
/* 
Gi Foe Oak Be PAE FRE Fe RHE ie Bee HE MEAS AE AE HE Mt AE ALAR aE TOs FASE Ae Be SAE Fok Bek ee AE OS ASAE AAS OEE HIS EAE BS SIE HE 
COUNTER: DO; 
DECLARE I Bue loon index / 


3 


Se 4b at 3% 


$ 3 3 TE St ot 


SS SS 


ARRAY (2) Peete, “external array =/ 
PROMPT(*) EYTS INITIAL(°VALUE IS: °), 


STATUSPORT LITERALLY “’@D8H’, 
DATAPORT Pika!  OPAk 
XMITRDY LITERALLY ‘2218’; 

[J FER PEERS AAS FE BE NE HE HRI BE OE AE OK 8 3 AK EAE AS HE NE IE AE BE AE TK SE AK AS CIE AE Ne eA AE DE eS AE AE AS A Hs 

/% 

- OUTCEAR is a procedure which tests the 

/* Sproreuis, Of “the Serial 1/0 pert that is 

i connected to the terminal. If the port 

/* i5 ready , an ASCII character is output 

ye to the CRT screen. 

J FR FR A ER ASS ETF ORS Hs SE HE BS EK BERS RE SHE HE TER HE ag REA BE ET ALT Ae BS SS AL HE 3S SS Se ES 


OUTCHAR: PROCEDURE (CHAB)} 
DECLARE CHAR BYTE; 
DO WEILE (INPUT(STATUSPORT) AND XMITRDY) = 
Mise, se Walt unital heady to transmit*/ 
OUTPUT(DATAPORT) = CHAR AND @7FE;} 
END; POT OUlGrar @eclaration */ 


Cs 


Mores =) 8, /* initialize sum “/ 


PL/M-&6 Source Listing 


Figure A-i 


eS 


ate 
oo 


wy 


st 


tt 3¢ 4b 2b 3 4 


2e 3 


SS NS 


os 
ee 
ae 





worl = 2 TO 9; -. 
/~* increment the sum */ 
BRPRAY(@) = APRAY(@) + 13 
END; /* of DO loop */ 
beer = 2 TO Po mene OMe); 
/* print the header */ 
mien OUTGHAR(PRCMPT(1)); 
om, /* of print loop */ 
PALL OUTCHAR(ARRAY(@)); /* print the sum */ 


myo; /* COUNTER1 program */ 


PL/M-86 Source Listing 


Fieure A-1l (contd) 
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\* wae a 
ii-« 3 eee 
Sane 


rEeone PRAT 7.-% 
“\* “dobsed sag ia 
(CE )OTe0ea) Me JA. 

\* wool Jatt te 


we 1108 TAKS eaEgtOg) 
metuose LeeteCos PY 


(arts 
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PLM-86 COMPILER COUNTER1 


ISIS-II PL/¥-86 ¥1.2 COMPILATION OF MODULE COUNTEP1 

OBJECT MODULE PLACED IN :F1:CNTR1.0BJ 

COMPILER INVOKED BY: PLMS6 :F1:CNTR1.SRC CODE LAGS 
DATE(1 JUNE &Z) 


[FAERIE RE REIT HS I HERE HE AE OK a SH a Re a HE ai fe Ne ea Ne He Re a aS a Re ae ea a Reale ae Reale a ae ea ee / 
/ zs 3s / 
/* Sample Program to demonstrate the software af, 
ye development utility programs used during * / 
/* syStem generation. This program Simply ai 
“a increments a global array element nine iy), 
a times and then prints the result on the at / 
y= terminal Screen. =) 
a a 
7 NN alte anor ance cena ie bis as oe S10 51k Ae oon Ore Suk Se See 35 G8 Sek Bye: SSeS See Bee eee tee Tan ek Tae Sek Bie eae Sak Oye De ne See ee OS SEBS Me BE Ole Se sre te iy 


i COUNTERI1: Do; 


2 1 HeCLAnhemet pen. /* loov index */ 
ARRAY(2) BY Tee TSRNAL. 
SROMPm(s )  BYTe INTTIAL( VALUE IS: ~~}, 
STATUSPORT MOT eR ALLY <GDeE @, 
DATAPORT MPT ERAGLY e-cDanH  . 
Meek, LITERALLY “@@1F°; 


8 Re He He He He He ee He He ae 2 ae ae Nee ae Sa ae Ree He eae ae of al a ae ae ae ae ea ea ae ae a is eae a a Ce / 
y xe oe / 
y* OUTCHAR is a procedure which tests the /) 
a status of the serial I/O port that is a7 
Ae connected to the terminal. If the port ** / 
/* is “ready , an ASCII character is output * / 
ye to the CPT screen. a7, 
/ oe a / 


whe we ae ee, Je he 4 whe 
[FR FE ERE REAR REFER RENE BET BE I AE EOE AE EK BE SE HE HS AS AEE ERE ME AE AS HS 2 EB RE HE FE ERE 2 BI AE AE HE AE FE / 


SB 1 OUTCHAR: PROCEDURE (CEAR); 
* STATEMENT # 3 


PL/M=86 Compiler Listine 


Figure A-2 
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Cn +P 


1 


Cars 
OO74 


OUTCHAR PROC NEAR 
a RUS 8 Pe 
SBEC MOV Bolg 


DECLARE CHAR BYTE; 


GOVE 
OO7E 
CC7E 
00'7D 


CZ EQ 


DOUWHITE (INPUT(STATUSPORT) AND XMITRDY) = €; 
END; 
; STATAMENT # 5 
Qi: 
B4D8 IN ADE 
F6CZ21 Tes T AL,1H 
T4023 iy $+5E 
EQ2@2e¢q JMP Q2 
es eT iMENT eG 
EQFSFT IMP G1 
(23 


GCES 
GZEG 
Gzea9 


Oger 
GZSc 


CECE 
ZBO9 
GOs 
O¢1i 
60123 
6018 


Bg AQ 
OO1E 
Boze 
0027 


CZ2C 
Cv2k 


OUTPUT(DATAPORT) = CHAR AND @7FH; 
y SLATE MONT 7 


BA4EG4 MOV AL,{ BD] .CEAR 
QEuO7F AND Ne 7 eh 
E6DA OD @TAH 
SND; 
TS TAO MENT 2 oe 
5D POP EP 
C22200 RET 2H 
OUTCHAR ENDP 


Peay (GO) =O; /* initialize sum */ 
; SHeTremMauNntT # °S 


FA Gil 

2E82160482 MOV SS,CS:G@STACKSFEAME 
RCZ6G¢2 MOV SP,CQSTACKSOFFSET™ 
SBEC MOV Be ce 

2ERE1LECESE MOV DS,CS:G@LDATASFRAMS 
FB ore 

2ZEC41EL LSC LES EX ,CS:@GARRAY 
26C6L72A MOY ES:ARRAV [BX] ,¢F 


DO = Ve TO 9, 
; STATEMENT # 12 


CELEGELLLE MOV le 
C3: 

BESESBLOGI CMP I ,9H 

7683 JE $+ 5B 

E9118¢ o MP @4 


Fewe-co Compiler Listing 


Figure A-2 (contd) 
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Hel 


ec 


13 


14 


15 


6 


Bee 


0031 
C¢ 36 


ao 
00 3D 
C23 


CO6E 
9263 
CZEE 


OOv1 
OLV2 


ARRAY(2) = ARRAY(D) + 13 


/* increment sum 


2EC41 BOCAS Lea 
LE6FEC7? INC 
che 7 DO LOOP / 
FEZ6CLLe INC 
7402 JZ 
EONEFF oe 
Q4 3 


DO I = @ TO LAST(PROMPT 


ae / 


> OTATEMENT 4 


Bee oo Chnnny 
HS :ARRAY [BX] 


3; SLATEMENT 
I 
SoH 


G3 


)s 

ei; 

; STATEMENT 
1,28 


I,@Az 
$+58 
6 


Peo SN Ty 
BL 

Be ou 
PCE ky 


OUTCEAR 


STATEMENT 


’ 
I 
S 
e 


+5 
jag 


/* print the header 
CE6CE6SSC ASP MOY 
ciey 
SOGSECACOGA Cie 
7683 JBE 
E91i522 JMP 
Comme OUTGHAR (PROMPT(1)); 
BALECE LE MOV 
BYCE Row 
FF77@1 PUSH 
ES1ELL GALL 
END; 
FEC6CLLL INC 
7403 ee 
EQE1FF J™MP 
G6: 


CALL OUTCHAR(ARRAY(2));3 


Vorint tie sum * / 
2EC41 ECC 22 LES 
Coline 4 PUSE 
BRECLSEL CALL 

END; wee POOUN TERI °/ 
FR Sl 
Fa BD 


STATEMENT 


Oe Go Car nay 
ES: ARRAY [PX] 


OUTCEAR 


> SLATEMENT 


PL/M-86 Compiler Listing 


Figure A-2 (contd) 
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MODULE INFORMATION: 


CODE ARSA SIZE OSSFH 143D 


CONSTANT AREA SIZE = @2OGEF GD 
VARIABLE AREA SIZE = @¢OCE fee 
MAXIMUM STACK SIZE = O@U6H 6D 


52 LINES READ 
@ PROGRAM ERROR(S) 


END OF PL/M-86 COMPILATION 
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Figure A-2 (contd) 
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forts —11 MCS—-86 LINKER, 
etiess sFL:sCNTR1.OFT, 
LINK MAP FOR :F1:CNTPI1. 


erat a ts. OE 200 


NRO TESTING 


Voie Ores. ei: 


LNK(COUNTER1 ) 


LOGICAL SEGMENTS INCLUDED: 


LENGTH ADDRESS SEGMENT CLASS 
G@QEFE  ------ COUNTER1 CODE CODE 
@QECE ------ COUNTER1 DATA DATA 
@Q06H ------ STACK STACK 
20H ------ MEMORY MEMORY 
@ZQCH  ------ ARRAYDEC_CODE COLE 
@@@2H ------ ARRAYDEC DATA DATA 


INPUT MODULES INCLUDED: 
SPI :sCNTR1.OBJ (COUNTER1) 
eF1:ARRAY.OBJ (ARRAYDEC) 


LINK86 Listing 


eae een at 
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Dois-11l MCS-S6 LOCATER, V1.1 INVOKED BY: 

LOC86 :F1i:CNTR1.INK TO :F1:CNTRL.RUN ADDRESSES (SEGMENTSS 
(COUNTER1 CODE(1@@OF),COUNTERI DATA(2Q6GE) ,STACK(302@H),S 
ARRAYDEC_DATA(3@€@@E),ARRAYDEC_CODE(31¢@@H),4 


MEMORY(31120H)))& 


SEGSIZE(STACK (+2@H)) RS(@ TO OFFFEH) 


pepo TAELE OF MODULE COUNTERI 
READ FROM FILS 
WMOITTEN TO FILE 


BASS OFFSET TYPE 
SGCGE O880H 
ARRAYDEC: 

S1iGH €&20H 

31@0R 8008 


> eOLS 
SYM 
LIN 


PUL 


Ses ON TRI. LN 
cf leon TR L.RUN 


5 eer BASE CORStr ies SIMEOL 

ARRAY 

AND LINES 

PenOn eo0gn ~~ O000R "SYM  APRAY 
3 


MEMORY MAP OF MOLULE COUNTER! 
READ FROM FILE 
WRITTEN TO FILS 


ews START ADDRESS 


SEGMENT MAP 


START 


G10@CH 
C20CCH 
G30C0H 
SOG@CH 
SILER 
S11¢¢H 


SOP 


C1284 
C2¢C RE 
030255 
SOOG1E 
SICECE 
SleeeOn 


LENGTH ALIGN NAMz 


ve 1 ONT R1 « EN 
sF1:SCNTRI.RUN 


PANAGRAPE = Q91@@H OF }SsT = 26¢C8E 


CLASS 


OOSFH W  COUNTERI CODE CODE 
@QECR WwW  COUNTER1_DATA DATA 
@@26H WwW STACK STAG & 
@Q@2E WwW  ARRAYDEC_DATA DATA 
CZ@2ZE YW ARRAYDEC CODE CODE 
OQOZE W MEMORY MEMORY 


ROCSG bist ine 


Figure A-4 
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